ETSITS101 882-2 V4.1.1 



(2003-09) 



Technical Specification 



Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON) Release 4; 

Protocol Framework Definition; 

Part 2: Registration and Service Attachment 

service meta-protocol definition 




u 



ETSI TS 101 882-2 V4.1.1 (2003-09) 



Reference 



RTS/TIPHON-03016-2R4 
Keywords 



interface, IP, meta-protocol, protocol, service, 
VoIP 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of thie present document can be downloaded from: 
fittp://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, send your comment to: 
editor(a)etsi.orq 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2003. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade IVlarks of ETSI registered for the benefit of its IVIembers. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



ETSI TS 101 882-2 V4.1.1 (2003-09) 



Contents 



Intellectual Property Rights 5 

Foreword 5 

Introduction 5 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 7 

4 Registration service 7 

4.1 Purpose 7 

4.2 Description 7 

4.3 Procedures 8 

4.3.1 Provision/withdrawal 8 

4.3.2 Normal procedures 8 

4.3.2.1 Activation/deactivation 8 

4.3.2.2 Invocation and operation 8 

4.3.3 Exceptional procedures 9 

4.4 Interaction with other services or service capabilities 9 

4.5 Overall behaviour 10 

5 Functional entity model and information flows 12 

5.1 Functional entity model 12 

5.1.1 Description of model 12 

5.2 Information flows 13 

5.2.1 Relationship ra 13 

5.2.1.1 Register 13 

5.2.1.2 DeRegister 14 

5.2.2 Relationship rb 14 

5.2.2.1 Authorize 14 

5.2.2.2 Detach 15 

5.2.3 Relationship re 15 

5.2.3.1 Attach 15 

5.2.4 Relationship rd 15 

5.2.4.1 Detach 15 

5.2.5 Summary of information element definitions 16 

5.2.6 Information flow sequences 16 

5.2.6.1 Normal operation 17 

5.2.6.1.1 Initial registration 17 

5.2.6.1.2 Change of SpoA (location update) 18 

5.2.6.1.3 DeRegistration 19 

5.2.6.2 Exceptional operation 20 

5.2.6.2.1 Invalid identity 20 

5.2.6.2.2 Service not available 21 

5.3 Registration functional entity actions 21 

5.3.1 Actions of RFEl 22 

5.3.2 Actions of RFE2 22 

5.3.3 Actions of RFE3 23 

5.3.4 Actions of RFE4 23 

5.4 Registration functional entity behaviour 23 

5.4.1 Behaviour of RFEl 23 

5.4.2 Behaviour of RFE2 28 

5.4.3 Behaviour of RFE3 34 

5.4.4 Behaviour of RFE4 37 

5.5 ASN.l data definitions 39 



£75/ 



4 ETSI TS 101 882-2 V4.1.1 (2003-09) 

5.6 Allocation of functional entities to domains 41 

Annex A (informative): Additional SDL used in modelling 42 

Annex B (informative): SDL model 52 

Annex C (informative): Bibliography 53 

History 54 



£75/ 



ETSI TS 101 882-2 V4.1.1 (2003-09) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 

The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [9]. 



Introduction 



The present document is a product in TIPHON Release 4 (see TR 101 301 [8]) of step C of the TIPHON development 
process described in ETSI TR 101 835 [7]. 
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Scope 



The present document defines by means of an information model, a functional entity behavioural model, and by 
validated SDL a model of the abstract behaviour of each service and service capability identified as being essential in 
TIPHON Release 4. 

The present document defines the meta-protocol requirement for the registration and service attachment services in 
TIPHON. 
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3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the following terms and definitions given in TR 101 877 [3] and 
TS 101 878 [4] apply. 



3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in TR 101 877 [3], TS 101 878 [4] and the following 
apply: 



FE 

IMSI 

MSC 

RFE 

SpoA 

UML 



Functional Entity 

International Mobile Subscriber Identity 
Message Sequence Chart 
Registration Functional Entities 
Service provider point of attachment 
Unified Modelling Language 



Registration service 



4.1 Purpose 



The purpose of the registration and service attachment service is to provide authorization of users to access services. In 
addition the registration and service attachment service provides a mechanism for security countermeasure CI as 
identified in TS 102 165-1 [6]. 



4.2 Description 



The registration service enables a user (the registrant) to seek and gain authority to invoke service in a domain for 
which access is strictly controlled. The service applications to be offered are determined, in part, by data held in the user 
profile. 

Figure 1 shows the relationship of the core elements in registration. 



Registrant 



User registration 
< ► 



Registrar 



Service preparation 



Service attachment 



SpoA 



Figure 1: Relationship of registration entities 

The registrar maintains a record of the location of the registrant and acts as an arbitrator on the provision of individual 
services to the registrant. Figure 2 shows by means of an UML class diagram the ordinality of the relationships to be 
considered in the registration and service attachment service. 
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A single user may be associated witli many registrants. 

A registrant sliall be associated witli only one user. 

A registrant sliall be associated witli only one registrar. 

A registrar may be associated with many registrants. 

A service may be associated with many service providers. 

In any registration instance a service shall be associated with only one service provider. 

A service provider shall be associated with only one Service. 

A registrant may be associated with many Services. 

Figure 2: Ordinal relations in TIPHON 



The registrar authorizes access to service appHcations in the domain in which the registrant is located or in another 
domain in which the entity controlling the service application is located. 

If the registrar determines that the user is no longer authorized for a service application or set of service applications, 
e.g. if a pre-paid account has been depleted, the registrar shall inform the registrant and the service provider. 

The registration service is offered across a network or set of networks (parts of which may be under different 
administrative control). 



4.3 



Procedures 



4.3.1 



Provision/withdrawal 



Registration is available on a per-name/per service basis to all customers of a TIPHON system. 

4.3.2 Normal procedures 

4.3.2.1 Activation/deactivation 

Registration shall be activated at provision and deactivated at withdrawal. 

4.3.2.2 Invocation and operation 

Registration shall be invoked by at least one of the following events: 

• on power-up of the user equipment; 

• on change of physical point of attachment; 

• on change of logical point of attachment; 
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• on demand by the user; and 

• on demand by the network. 

A user shall indicate in a registration request those services to be registered to and shall be informed by the registrar 
where those services can be provided. 

If a registrant registers from a new location to a service it is already registered to and a new service provider is allocated 
the registrar shall be able to delete the registrant's details from the old serving service provider. 

4.3.3 Exceptional procedures 

If the registrar is unable to determine where the requested service can be provided it shall inform the registrant with an 
indication of the reason for the rejection of the registration request. Possible rejection causes include inadequate 
capacity at an available service provider to maintain the required level of service. 

4.4 Interaction with other services or service capabilities 

The registration and service attachment service described in the present document implements the following service 
capabilities defined within the Profile class of TS 101 878 [4] for TIPHON Release 4: 

attach; 

authorize; 

deregister; 

detach; and 

register. 

In addition the service capability authenticate may be invoked during registration. In such cases any failure of 
authentication shall terminate registration without the authorization of service to the registrant. 

Some capabilities of the call and bearer classes may, depending on the overall service definition, be dependent upon the 
use of service capabilities which are described in the present document. The interaction with services and service 
capabilities implemented in such services is outside the scope of the present document. 
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4.5 Overall behaviour 

The overall behaviour is shown in figures 3 and 4 for the registration service. 



^ 



Activated 



Registration request 



Registration accepted and SpoA identified/ \. Registration rejected 






Attacliment request 



Attachment rejected 



Attacliment accepted 

\/ . 

Service 

attaclied 



-^m'"^ 



Figure 3: Overall behaviour for registration service expressed as an UML activity diagram 
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Registrar 
Profile 



Registrant : 
NGNUser 



SpoA : Profile 



register( ) 



attach ( ) 



authorise( ) 



deregister( ) 



detach ( ) 



Figure 4: Overall behaviour in terms of TIPHON service capabilities 
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5 Functional entity model and information flows 

5.1 Functional entity model 
5.1 .1 Description of model 

The functional model shall comprise the following Registration Functional Entities (RFE): 

Table 1 : Registration functional elements 



Identity 


Description 


Registering user 




RFE1 


Registrant, tlie logical entity being registered 


RFE2 


Registrar, holder of user profile of the registrant 


RFE3 


Serving service provider point of Attachment (SpoA) 


RFE4 


Previous SpoA 




Figure 5: Relationships between functional entities for registration 
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system Registration 



RegUser 



ru d ru u 



RFE1 



ra d 



rc_d 



rc 



ra 



RFE4 



[rd.dj 

,rd 

[rdul 



RFE2 



rb_d 



rb 



rb_u 



RFE3 



Figure 6: Relationships between functional entities for registration as SDL system diagram 

5.2 Information flows 

The following conventions are used to identify information flows: 

• an information flow is referred to as a "request" at the FE that sends it and as an "indication" at the FE that 
receives it, this is shown in the tables defining each information flow as "req_ind"; 

• the corresponding confirmation is referred to as a "response" at the FE that sends it and as a "confirmation" at 
the FE that receives it, this is shown in the tables defining each information flow as "resp_conf". 

5.2.1 Relationship ra 
5.2.1.1 Register 

Register is a confirmed information flow used by RFEl to request the RFE2 to open the user's profile. 
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Table 2: Register information flow 



Information element 


Value 


Reqjnd 


Resp_conf 


TIPHON-reg-id 


Any 


M 


M 


RegistrationMode 


Initial registration 
Location update 


M 


- 


Location 


Any 


M 


- 


ServiceName 


TIPHONSimpleCall 


M 


(see note 2) 


Result 


Registration successful 
Registration-Id invalid 
Service unavailable 




M 


ServiceProviderName 


Any 


- 


(see note 1) 


ClientAuthorisationToken 


Any 


- 


(see note 1) 


NOTE 1 : Provided if Result = "Registration successful". 
NOTE 2: Provided if Result = "Service unavailable". 



5.2.1.2 DeRegister 

DeRegister is a confirmed information flow that shall be used by RFEl to request clearance of service attachments. 

Table 3: DeRegister information flow 



Information element 


Value 


Req ind 


Resp conf 


TIPHON-reg-id 


Any 


M 


IVI 


ServiceName 


TIPHONSimpleCall 


M 


- 


Result 


Deregistration successful 
Registration-Id invalid 


- 


M 



5.2.2 Relationship rb 



5.2.2.1 



Authorize 



The Authorize information flow shall be used by RFE2 to request RFE3 for authorization to allow a client to attach for 
service. 

Table 4: Authorize information flow 



Information element 


Value 


Reqjnd 


Resp conf 


Registrar-id 


Any 


M 


M 


TIPHON-reg-id 


Any 


M 


M 


ServiceName 


TIPHONSimpleCall 


M 


- 


ClientAuthorisationToken 


Any 


- 


(see note) 


Result 


Service authorized to client 
ResourceNotAvailable 


- 


M 


NOTE: This information element shall be provided if the value of Result is "OK". 



£75/ 



15 



ETSI TS 101 882-2 V4.1.1 (2003-09) 



5.2.2.2 Detach 

The detach information flow shall be used by RFE2 to inform RFE3 that a client has requested deregistration from the 
service. 

Table 5: Detach information flow 



Information element 


Value 


Reqjnd 


Resp_conf 


Registrar-id 


Any 


M 


M 


TIPHON-reg-id 


Any 


M 


M 


ServiceName 


TIPHONSimpleCall 


M 


- 


Result 


Service detachment successful 
Identity not recognized 


- 


M 



5.2.3 Relationship re 



5.2.3.1 Attach 

The attach information flow shall be used by RFEl to request attachment to RFE3. 

NOTE: The service attachment may be sent at service invocation of the service to be attached. 

Table 6: Attach information flow 



Information element 


Value 


Reqjnd 


Resp_conf 


Registrar-id 


Any 


M 


M 


TIPHON-reg-id 


Any 


M 


M 


ServiceName 


TIPHONSimpleCall 


M 


- 


AuthorisationToken 


Any 


M 


- 


Result 


Service attachment successful 
Identity not recognized 
Authorization expired 




M 



5.2.4 Relationsinip rd 



5.2.4.1 Detach 

The detach information flow shall be used by RFE2 to inform RFE4 that a client should no longer be offered service. 

Table 7: Detach information flow 



Information element 


Value 


Req ind 


Resp conf 


Registrar-id 


Any 


M 


M 


TIPHON-reg-id 


Any 


M 


M 


ServiceName 


TIPHONSimpleCall 


M 


- 


Result 


Service detachment successful 
Identity not recognized 


- 


M 
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5.2.5 Summary of information element definitions 

This clause further defines the information elements present in each of the information flows defined in clauses 5.2.1 
through 5.2.4. 

TIPHON-reg-id: A unique name used to identify the registrant. This name should be structured in such a way that the 
home containing the registrant's profile (i.e. the Registrar) can be determined. 

EXAMPLE: The International Mobile Subscriber Identity (IMSI) used in GSM may be considered as an 
example of TIPHON-reg-id. 

RegistrationMode: This element indicates to the registrar if the user is registering for the first time, or wishes to 
update/refresh a previous registration. This is defined as an extensible list. 

Location: This element indicates the current location of the registrant, and allows the registrar to offer a service 
provider local to the registrant where the service requires it (e.g. for any service where QoS is guaranteed). May be 
provided as a network address (e.g. IPv4 or IPv6 address, telephone number of a fixed line) or as a geographic location 
depending upon the service requested. 

ServiceName: This element identifies the service that is to be registered to. The name has to be meaningful to each 
party in the registrant facing group (i.e. registrant, registrar, SpoA). This is defined as an extensible list. 

Result: This element provides the result to any information flow and appears in the "_resp_conf" flows. 

Service Pro viderName: A unique name used to identify the SpoA. This name should be structured in such a way that 
the address of the SpoA can be determined using conventional resolution protocols. 

ClientAuthorisationToken: This is an authorization token prepared by the SpoA in response to the Authorise_req_ind 
information flow and is intended to be given back by the client at "attach" for verification. The format of the token is 
not fully defined in the present document. 

Registrar-id: A unique name used to identify the registrar. This name should be structured in such a way that the 
address of the registrar can be determined using conventional resolution protocols. 

AuthorisationToken: see ClientAuthorisationToken. 

5.2.6 Information flow sequences 

This clause specifies the information flow sequences for the registration and service attachment service. 

NOTE 1 : The information flow sequences are produced with a MSC editor; however, the scenarios are not MSCs 
but information flow sequences as defined in ITU-T Recommendation 1.130 [5]. 

NOTE 2: In accordance with the ITU-T Recommendation 1.130 [5] the invoking side is placed as the leftmost entity 
in the information flow sequences. 

The step D for registration and service attachment shall provide signalling procedures in support of the information flow 
sequences specified in this clause. In addition, signalling procedures should be provided to cover other sequences 
arising from error situations, interactions with simple call, interactions with different topologies, etc. 

In the information flow sequences, registration and service attachment information flows are represented by arrows. 

The following information flow sequences are intended as guidance in further development. 
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5.2.6.1 Normal operation 

5.2.6.1 .1 Initial registration 



RFE3 



Register_req_ind 



(TIPHON-reg-id, RegistrationMode, 
Location, ServiceName 



Authorise_req_ind 



(Registrar-id, 

TIPHON-reg-id, 

ServiceName 



Authorise_resp_conf 



( Registrar-id, TIPHON-reg-id, 
ClientAuthorisationToken, Result) 



Register_resp_conf 



( TIPHON-reg-id, Result, 

ServiceName, ServiceProviderName 

ClientAuthorisationToken) 



Attachreqjnd 



(TIPHON-reg-id, registrar-id, 
ServiceName, AuthorisationToken ) 



Attach_resp_conf 



( TIPHON-reg-id, registrar-id. Result) 



Figure 7: Normal initial registration 
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5.2.6.1.2 



Change of SpoA (location update) 



Register_req_ind 



(RegistrationMode, Location, ServiceName ) 



Authorise_req_ind 



{Registrar-id, 
TIPlHON-reg-id, 
ServiceName ) 



Authorise_resp_conf 



( Registrar-id, TIPHON-reg-id, 
ClientAuthorisationToken, Result) 



Register_resp_conf 



TIPHON-reg-id, Result 



ServiceName, ServiceProviderfJame 

ClientAuthorisationToken?06 



Detach_req_ind 



{TIPHON-reg-id, Registrar-id, ServiceName ) 



Detach_resp_conf 



( TIPHON-reg-id, Registrar-id, Result) 



Attach_req_ind 



{TIPHON-reg-id, registrar-id, 
ServiceName, AuthorisationToken ) 



Attach_resp_conf 



( TIPHON-reg-id, registrar-id. Result) 



Figure 8: Normal location update (roaming) 
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5.2.6.1.3 



DeRegistration 



De Reg iste r_rec|_ind 



(TIPHON-reg-id, ServiceName 



Detach_req_ind 



(Registrar-id, 
TIPHON-reg-id, 
ServiceName ) 



Detach_resp_conf 



( Registrar-id, TIPHON-reg-id, Result) 



DeRegister_resp_conf 



( TIPHON-reg-id, Result) 



Figure 9: DeRegistration normal behaviour 
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5.2.6.2 Exceptional operation 

5.2.6.2.1 Invalid identity 



Registerreqjnd 



(TIPHON-reg-id, RegistrationMode, 
Location, ServiceName 



Register_resp_oonf 



( TIPHON-reg-id, Result) 



Figure 10: Exceptional behaviour - invalid identity 
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5.2.6.2.2 



Service not available 



Register_req_ind 



(TIPHON-reg-id, RegistrationMode, 
Location, ServiceName 



Authorise_req_ind 



(Registrar-id, 
TIPHON-reg-id, 
ServiceName ) 



Authorise_resp_conf 



( Registrar-id, TIPHON-reg-id, Result) 



Register_resp_conf 



TIPHON-reg-id, Result) 



Figure 11 : Exceptional behaviour - service not available 



5.3 Registration functional entity actions 

Throughout the descriptions of FE actions, the following conventions are used to identify information flows: 

• an information flow is referred to as a "request" at the FE that sends it and as an "indication" at the FE that 
receives it, this is shown in the actions of each FE as "req_ind"; 

• the corresponding confirmation is referred to as a "response" at the FE that sends it and as a "confirmation" at 
the FE that receives it, this is shown in the actions of each FE as "resp_conf' . 

The following FE actions shall occur at the points indicated in the information flow sequences of clause 5.2. 
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5.3.1 Actions of RFE1 

101: On request RFEl shall prepare a Register_req_ind information flow setting the RegistrationMode 

element to "initial registration" and other elements as appropriate (i.e. location, ServiceName, 
TIPHON-reg-id) and send it to RFE2; 

102: On receipt of the Register_resp_conf information flow RFEl shall extract the result element. If 

result is "Registration successful" RFEl shall undertake action 103, else is shall undertake action 
106; 

103: From the received Register_resp_conf information flow RFEl shall prepare an Attach_req_ind 

information flow containing the received AuthorisationToken and send it to RFE3 (identified by 
resolving the received ServiceProviderName); 

104: On receipt of the Attach_resp_conf information flow RFEl shall check the result element and if 

the value is "Service attachment successful" shall be able to invoke that service through that SpoA. 
If the result is not "Service attachment successful" the service shall be barred; 

105: RFEl shall prepare a Register_req_ind information flow setting the RegistrationMode element to 

"Location update" and other elements as appropriate (i.e. location, ServiceName) and send it to 
RFE2; 

106: The registration process shall stop, however further attempts to register are possible by invoking 

action 101; 

107: On request RFEl shall prepare a DeRegister_req_ind information flow identifying the service to 

be deregistered and send it to RFE2; 

108: On receipt of DeRegister_resp_conf information flow RFEl shall be inhibited from invoking the 

deregistered service. 

5.3.2 Actions of RFE2 

201 : On receipt of Register_req_ind information flow RFE2 shall validate the received TIPHON-reg-id 

and if valid shall retrieve the related profile. RFE2 shall also determine the type of registration 
requested, if InitialRegistration shall follow operation 202, else shall follow operation 205; 

202: For the service identified in the Register_req_ind information flow RFE2 shall identify an 

appropriate SpoA and prepare an Authorise_req_ind information flow to send to RFE3; 

203: On receipt of the Authorise_resp_conf information flow RFE2 shall check the Result. If not 

"Service authorized to client" then exceptional behaviour action 211; 

204: RFE2 shall prepare the response to Register_req_ind. If the Authorise_resp_conf is "Service 

authorized to client" then RFE2 shall set the result element in Register_resp_conf to 
"RegistrationSuccessful" ; 

205: If TIPHON-reg-id is not valid RFE2 shall prepare the Register_resp_conf setting the result 

element to "Registration-id invalid"; 

206: On acceptance of a new SpoA RFE2 shall revoke the provision of service on the old serving SpoA 

by sending Detach_req_ind to RFE4; 

207: On receipt of Detach_resp_conf RFE2 shall update the availability record of the registrant 

(i.e. update the content of the user -profile); 

208: On receipt of Deregister_req_ind RFE2 shall validate the received TIPHON-reg-id and if valid 

shall retrieve the related profile to determine if the service is enabled and to identify the SpoA 
(RFE3) currently serving that service; 

209: RFE2 shall withdraw the provision of service on the serving SpoA by sending Detach_req_ind to 

RFE3; 
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210: RFE2 shall prepare Deregister_resp_conf. If the identity was valid and if Detach_resp_conf was 

successful then RFE2 shall set the result element of Deregister_resp_conf to 
"DeRegistrationSuccessful"; 

211: RFE2 shall prepare the Register_resp_conf setting the result element to "Service Unavailable" and 

identifying the service that gave rise to the error. 

5.3.3 Actions of RFE3 

301 : On receipt of Authorise_req_ind RFE3 shall determine if it can provide resource to allow the user 

to be offered service; 

302: If service can be provided RFE3 shall prepare Authorise_resp_conf setting result to "Service 

authorized to client" and adding the ClientAuthorisationToken prior to sending to RFE2; 

303: On receipt of Attach_req_ind RFE3 shall validate the TlPHON-reg-id and the authorization token; 

304: RFE3 shall prepare Attach_resp_conf setting result to "Service attachment successful" and allow 

invocation of the service to the user; 

305: If service cannot be provided RFE3 shall prepare Authorise_resp_conf setting result to "Resource 

not available" and send it to RFE2; 

306: If the TIPHON-reg-id is not recognized by RFE3 it shall prepare Attach_resp_conf setting result to 

"Identity not recognized". If TIPHON-reg-id is recognized but the AuthorisationToken is no 
longer valid RFE3 shall prepare Attach_resp_conf setting result to "Authorization expired"; 

307: On receipt of Detach_req_ind RFE3 shall validate the received data and cease to offer service to 

the user and set result to "Service detachment successful". If validation fails the Result shall be set 
to "Identity not recognized"; 

308: RFE3 shall prepare Detach_resp_conf with the result set from action 307 and send it to RFE2. 

5.3.4 Actions of RFE4 

401 : On receipt of Detach_req_ind RFE4 shall validate the received data and cease to offer service to 

the user and set result to "Service detachment successful". If validation fails the Result shall be set 
to "Identity not recognized"; 

402: RFE4 shall prepare the Detach_resp_conf with the result set from action 401 and send it to RFE2. 

5.4 Registration functional entity behaviour 

NOTE: In the SDL process diagrams labels, where used, correspond to the numbered actions of each FE as given 
in clause 5.3. 

5.4.1 Behaviour of RFE1 

The behaviour of RFEl is shown in the SDL process diagram in figures 12 through 16. 
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SYSTEM Registration re 



re u 



rc 



rc_d) 



RegUser 

(ru_d) I I (ru_u 

SYSTEIVi Registration RegUser 



RFE1 



ra_d) 



ra 

[(ra_u) 
SYSTEIVi Registration ra 



Figure 12: Block RFE1 



/** Default values are provided for simulation only 
and fiave no meaning for the core model *7 



1\ 



InitialRegistration 




DCL 

register_ri 
register_rc 
RegistrationResult 
attach_ri 
attacfi_rc 
AttachResult 
TiphionRegId 
ServiceName 
Location 



register_request := Default_RegistrationReq, 
register_response := Default_RegistrationResp, 
RegistrationResultType := Default_RegistrationResLilt: 
attach_request := Default_ServiceAttachReq, 
attach_response := Default_ServiceAttachResp, 
Attach ResultType := Default_AttachResult, 
TiphonReglDType := Default_TiphonReglD, 
ServiceNametype := Default_ServiceName, 
LocationType := Default_LocationType; 



UserSignal (user_request) 



reque^ 

LocationUpdate 





DeRegister 




Figure 13: Process RFE1, 1 of 4 
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Builcl_RegisterRequest (locUpdate, register_ri) 




Build_RegisterRequest (initialRegistration, register_ri) 



register_req (register_ri) VIA ra 



WaitRegisterResponse 



register_resp (register_rc) 



RegistrationResult := Result_From (register_rc) 




registrationSuccessful 



Normal behaviour 




ELSE 



IDLE 



Figure 14: Process RFE1, 2 of 4 
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TiphonRegId :=TiphonRegld_From (register_rc) 



ServiceName := ServiceName_From (registerri) 



Build_AttachRequest (registerrc, TiphonRegId, ServiceName, Attachri) 



attachreq (attacli_ri) VIA re 



WaitAttaclnResponse 



attacli_resp (attacli_rc) 




AttachResult := AttachResult_From (attacli_rc) 



ServiceAttachmentSuccessful 



RegisterService (attacli_ri) 



MX 



ELSE 



IDLE 



IDLE 



Exceptional 
behaviour 



Figure 15: Process RFE1, 3 of 4 
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Build_DeRegisterRequest (deregister_ri) 



deregister_req (deregister_ri) VIA ra 



WaitDeRegisterResponse 



deregister_resp (deregister_rc) 



IDLE 



Figure 16: Process RFE1, 4 of 4 
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5.4.2 Behaviour of RFE2 

The behaviour of RFE2 is shown in the SDL process diagram in figures 17 through 23. 

SYSTEM Registration rd 

[(rd_u)l 



rd 



ra 



(ra_d)J L(ra_u)j 

SYSTEIVI Registration ra 




rb 

(rb_d)] ^(rb_u 

SYSTEIVI Registration rb 



Figure 17: Block RFE2, 1 of 1 
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IDLE 



DCL N 

RegistrationRequest register_request := Default_RegistrationReq, 
TiphonRegId TiphonReglDType := Default_TiphonReglD, 

ServiceClientAuthRequest authorise_request := Default_ServiceClientAuthReq, 
RegistrationResponse register_response := Default_RegistrationResp, 
ServiceClientAuthResponse authorise_response := Default_ServiceClientAuthResp, 
AuthResult AuthorisationResultType := Default_AuthorisationResult, 

Profile ProfileType, 

ValidReg Boolean, 

RegMode RegistrationModeType := Default_RegistrationMode; 



register_req(RegistrationRequest) 



deRegister_req(DeRegistrationRequest) 



TiphonRegId := 

TiphonRegld_From (RegistrationRequest) 



ValidateRegId (TiphonRegId, ValidReg) 



false 







GetProfile (TiphonRegId, Profile) 



RegMode := 

Reg I stration Mode_From 

(RegistrationRequest) 



IdentifySpoA 

(ServiceName, Location, SpoA) 



LocationUpdate 




Figure 18: Process RFE2, 1 of 6 
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ServiceAuthorisedToClient 



del K 

NewSpoA Boolean, 
ServieeName ServieeNameType, 
Location LoeationType, 
SpoA ServieeProviderNameType 



Bulld_AuthorlseRequest () 



authorise_req(AuthoriseRequest) VIA rb 




WaitAuthoriseResponse 



authorise_resp(AuthoriseResponse) 



AuthResult '- AuthorisationResult_From (AuthoriseResponse) 



ResoureeNotAvailable 



Build_RegisterRespense 
(RegistrationSueeessf ul , 
TiphonRegId, 
RegistrationResponse) 



Build_RegisterResponse 
(ServieeUnavailable, 
TiphonRegId, 
RegistrationResponse) 



RegisterResp(RegistrationResponse) VIA ra 



IDLE 



Figure 19: Process RFE2, 2 of 6 



ETSI 



31 



ETSI TS 101 882-2 V4.1.1 (2003-09) 



false 



ServiceAuthorisedToClient 




SpoAChange{NewSpoA, CurrentSpoA, SpoAChange) 




Build_RegisterResponse 
(RegistrationSuccessful, 
TiphonRegId, 
RegistrationResponse) 



Build_AuthoriseRequest () 



authorise_req{AuthoriseRequest) VIA rb 



WaitAuthoriseResponse 



authorise_resp(AuthoriseResponse) 



AuthResult := AuthorisationResult_From (AuthoriseResponse) 



ResourceNotAvailable 



RegisterResp(RegistrationResponse) VIA ra 



Build_RegisterResponse 
(ServiceUnavailable, 
TiphonRegId, 
RegistrationResponse) 



RegisterResp(RegistrationResponse) VIA ra 



'A/ 

IDLE 



Figure 20: Process RFE2, 3 of 6 
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Build_DetachRequest (TiphonRegId, DetachRequest) 



Detach_req (DetachRequest) VIA rd 



Wa tDetach Response 



Detach_resp (Detach Response) 



IDLE 



Figure 21 : Process RFE2, 4 of 6 
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This process model shows the exceptional behaviour when the Identity of the registrant is invalid 

** / 




Build_RegisterResponse (Regldlnvalid, TiphonRegId, RegistrationResponse) 



RegisterResp(RegistrationResponse) VIA ra 



IDLE 



Figure 22: Process RFE2, 5 of 6 
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false 



IDLE 




TiphonRegId := 

TiphonRegld_From (DeRegistrationRequest) 



ValidateRegId (TiphonRegId, ValidReg) 



ValidReg 
true 



GetProfile (TiphonRegId, Profile) 



Detach_req(DetachRequest) VIA re 



WaitDetach Response 



Detach_resp (DetachResponse) 



Build_DeRegistrationResponse (DeRegistrationResponse) 



DeRegistration_resp(DeRegistrationResponse) VIA ra 



IDLE 



Figure 23: Process RFE2, 6 of 6 

5.4.3 Behaviour of RFE3 

The behaviour of RFE3 is shown in the SDL process diagram in figures 24 through 21. 



rc 



rb 



^ RFE3 

(rc_d)] [(rc_u)] \ ^ [(rb_u)J [(rb_d) 

SYSTEM Registration rc SYSTEM Registration rb 

Figure 24: Blocic RFE3, 1 of 1 
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'A/ 

IDLE 



DCL 


K 


AuthoriseRequest 


authorise request, 


Support 


Boolean, 


AuthoriseResponse 


authorise response. 


AttachRequest 


attach request, 


Attach Response 


attach response. 


Detach Request 


detech request, 


Detach Response 


detach response. 


AuthToken 


AuthorisationTokenType 


AuthTokenStatus 


Boolean, 


TiphonRegId 


TiphonReglDType, 


Reg Id Valid 


Boolean; 



Attach_req (AttachRequest) 





Detach_req(DetachRequest) 



OfferService(AuthoriseRequest, Support) 



true 




Authorise_req 
(AuthoriseRequest) 



Build_AuthResp(ServiceOffered, AuthoriseResponse) 



Authorise_resp(AuthoriseResponse) VIA rb 



^z 

IDLE 



Build_AuthResp 

(ResourceNotAvailable, 

AuthoriseResponse) 

Authorise_resp 

(AuthoriseResponse) 

VIArb 



IDLE 



Figure 25: Process RFE3, 1 of 3 
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AuthToken := AuthorisationToken_From (AttachRequest) 



true 



CheckAuthToken (AuthToken, AuthTokenStatus) 




AuthTokenStatus 



false 



TiphonRegId := TiphonReglD_From(AttachRequest) 



Build_AttachResp(AuthorisationExpired, AttachResponse) 



attach_resp(Attach Response) VIA re 



ValidRegld(TiphonRegld, RegldValid) 



IDLE 



Build_AttachResp(identityNotRecognised, AttachResponse) 



Build_AttachResp(AttachSuccessful, AttachResponse) 



attach_resp(Attach Response) VIA re 



attach_resp(Attach Response) VIA re 



Figure 26: Process RFE3, 2 of 3 



IDLE 
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true 




ValidateDetachReq (DetachRequest, ValidDetachRequest) 



ValidDetachRequest 



RevokeService (TiphonRegId) 



This procedure will revoke any crypto material held by the SpoA 



Build_DetachResponse (DetachSuccessful, DetachResponse) 



false 



Detach_resp{DetachResponse) VIA rb 



Build_Detach Response (identityNotRecognised, DetachResponse) 



Detach_resp{Detach Response) VIA rb 



IDLE 

Figure 27: Process RFE3, 3 of 3 

5.4.4 Behaviour of RFE4 

The behaviour of RPE4 is shown in the SDL process diagram in figures 28 and 29. 



IDLE 



SYSTEM Registration rd 



(rd_u) 



(rd_d) 



rd 



RFE4 



Figure 28: Blocic RFE4, 1 of 1 
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DCL 

ValidDetachRequest booleaH; 



true 



IDLE 



IDLE 



Detach_req (DetachRequest) 




ValidateDetachReq (DetachRequest, ValidDetachRequest) 



Valid Detach Request 



RevokeService (TiphonRegId) 



This procedure will revoke any crypto material held by the SpoA 



Build_DetachResponse (DetachSuccessful, DetachResponse) 



Detach_resp(DetachResponse) 



Build_DetachResponse (IdentityNotRecognised, DetachResponse) 



Detach_resp(DetachResponse) 



false 



IDLE 



Figure 29: Process RFE4, 1 of 1 
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5.5 ASN.1 data definitions 

— Registration information element ASN.l data types 

TiphonReglDType ;;= Visiblestring 

RegistrationModeType ::= ENUMERATED 
{ 

initialRegistration (0), 

locationUpdate (1) 
} 

ServiceNameType ;:= Visiblestring 

RegistrationResultType ::= ENUMERATED 
{ 

registrationSuccessful, 

regist rat ionID Invalid^ 

serviceUnavailable 
} 

ServiceProviderNameType ::= Visiblestring 

AuthorisationTokenType ;;= Visiblestring 

DeregistrationResultType ::= ENUMERATED 
{ 

deRegistrationSuccessful, 

Registration ID Invalid 



Registrar IDType 



Visiblestring 



AuthorisationResultType ::= ENUMERATED 
{ 

serviceAuthorisedToClient ^ 

resourceNot Available 



AttachResultType 



ENUMERATED 



serviceAttachment Successful, 
ident it yNot Recognised, 
author isationExp ire d 



RevokeRe suit Type 



ENUMERATED 



serviceDetachment Successful, 
ident it yNot Re cognised 



TRL : := SEQUENCE 

{ 

protocolID Visiblestring, 
nameorAddress Visiblestring, 
port Integer OPTIONAL 



— Data structures for registration signals — 
Register„req_ind_type ::= SEQUENCE 



tiphonRegID 
registrationMode 
location 
serviceName 



TiphonReglDType, 
RegistrationModeType, 
TRL, 
ServiceNameType 



Register_resp_conf_type ; 
{ 

tiphonRegID 

serviceName 

result 

serviceProviderName 



SEQUENCE 

TiphonReglDType, 
ServiceNameType OPTIONAL, 
RegistrationResultType, 
ServiceProviderNameType OPTIONAL, 



clientAuthorisationToken AuthorisationTokenType OPTIONAL 
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cleregister_req_incl_type 



SEQUENCE 



tiphonRegID 
serviceName 



TiphonReglDType, 
ServiceNameType 



cleregister_resp_conf„type :;= SEQUENCE 

{ 

tiphonRegID TiphonReglDType, 

result DeregistrationResultType 



authorise_req„ind_type ::= SEQUENCE 

{ 

registrarlD RegistrarlDType, 
tiphonRegID TiphonReglDType, 
serviceName ServiceNameType 



authorise_resp_conf_type : : 
{ 

registrarlD 

tiphonRegID 

client Author i sat ionToken 

authori sat ionRe suit 
} 



= SEQUENCE 

RegistrarlDType, 
TiphonReglDType, 

AuthorisationTokenType OPTIONAL, 
Author is at ionRe suit Type 



detach_req_ind_type 



SEQUENCE 



registrarlD 
tiphonRegID 
serviceName 



RegistrarlDType, 
TiphonReglDType, 
ServiceNameType 



detach_resp_conf_type 



SEQUENCE 



registrarlD 
tiphonRegID 
result 



RegistrarlDType, 
TiphonReglDType, 
RevokeRe suit Type 



attach_req_ind„type 



SEQUENCE 



registrarlD 
tiphonRegID 
serviceName 
author is at ionToken 



RegistrarlDType, 
TiphonReglDType, 
ServiceNameType, 
AuthorisationTokenType 



attach_resp_conf„type 



SEQUENCE 



registrarlD 
tiphonRegID 

attachResult 



RegistrarlDType, 
TiphonReglDType, 
AttachResult Type 
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5.6 



Allocation of functional entities to domains 



The possible allocation of FEs to TIPHON is shown in table 8. 



Table 8: Allocation of FEs to TIPHON domains 



Scenario 


RFE1 


RFE2 


RFE3 


RFE4 


1 


Terminal 


Home Service provider 


Home Service provider 


- 


2 


Terminal 


Home Service provider 


Visited Service provider 


- 


3 


Terminal 


Home Service provider 


Visited Service provider 


Home Service provider 


4 


Terminal 


Home Service provider 


Home Service provider 


Visited Service provider 


5 


Terminal 


Home Service provider 


Visited Service provider 


Visited Service provider 












Scenario 1 is initial registration at home. 

Scenario 2 is initial registration at a visited network. 

Scenario 3 is location update on roaming to a new SpoA in a visited network (moving from home to not-home). 

Scenario 4 is location update on roaming to a new SpoA in the home network (moving home from not-home). 

Scenario 5 is location update between on roaming between two visited SpoAs. 
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Annex A (informative): 
Additional SDL used in modelling 



The SDL procedures identified here have been developed in the modelHng exercise to allow validation and simulation 
of the process diagrams shown in clause 5. 



USE TV)4'£iri Re4E^aK]ri Typds; 

IrKF Q»i*lfr*_F^_ASW1_T^p«; 
USEDeiatBeiniod^ 



Sviton Red^rilcn 



^ ^ 



[ (nufl ] [ iJtjH ] 



RFE1 



[HjH ] 
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rd 



[ St*Jf) ] [ ft*_M) ] 



[ HJO ] 



[C^JJ] 



JJfE^ 



[Crt_i0 ] 
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WIS 
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Figure A.I : System Registration, 1 of 3 
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Figure A.2: System Registration 2 of 3 
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Figure A.3: System Registration 3 of 3 
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Figure A.4: Procedure Build_RegistrationReq 
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Figure A.5: Procedure Build_ServiceAttachReq 
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Figure A.6: Procedure RegisterService 
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Figure A.7: Procedure ValidateRegID 
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Figure A.8: Procedure GetProfile 
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Figure A.9: Procedure Build_ServiceClientAuthReq 
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Figure A.10: Procedure Build_RegistrationResp 
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Figure A.11: Procedure GetTiphonRegId 
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Figure A.12: Procedure ValidateRevoiceReq 
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Figure A.13: Procedure DetachServiceSupport 
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Figure A.14: Procedure Build_ServiceClientRevokeResp 
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Figure A.15: Procedure AddServiceSupport 
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Figure A.16: Build_ServiceAttachResp 
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Figure A.17: Procedure CliecicAutliToicen 
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Figure A.18: Procedure ValidRegID 
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Figure A.19: Procedure OfferService 
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Figure A.20: Procedure Build_ServiceClientAuthResp 
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Annex B (informative): 
SDL model 



The attached file represents the SDL model of TIPHON registration meta-protocol (developed using the Cinderella tool 
(a viewer is available from http://www.cinderella.dk) . 
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